home *** CD-ROM | disk | FTP | other *** search
/ NetNews Offline 2 / NetNews Offline Volume 2.iso / news / comp / lang / c-part2 / 15753 < prev    next >
Encoding:
Internet Message Format  |  1996-08-05  |  2.2 KB
  1. Path: ix.netcom.com!news
  2. From: miker3@ix.netcom.com (Mike Rubenstein)
  3. Newsgroups: comp.lang.c
  4. Subject: Re: Stylistic Concerns with Header Files
  5. Date: Sun, 21 Apr 1996 14:36:41 GMT
  6. Organization: Netcom
  7. Message-ID: <317a471b.42264192@nntp.ix.netcom.com>
  8. References: <4lb9bl$amo@wormer.fn.net>
  9. NNTP-Posting-Host: ix-dc19-08.ix.netcom.com
  10. X-NETCOM-Date: Sun Apr 21  9:36:00 AM CDT 1996
  11. X-Newsreader: Forte Agent .99d/32.182
  12.  
  13. withheld@keepitpublic.com (Rusty Meathook) wrote:
  14.  
  15. > I occasionally create the undesirable situation of having to include
  16. > my header files in a certain order, or having to include one header
  17. > file to include another, and I was wondering how I can circumvent
  18. > that.  The most common case is something like this:
  19. > 
  20. > /* Untested code; call this "foo.h" */
  21. > 
  22. > #ifndef _FOO_H_
  23. > #define _FOO_H_
  24. > 
  25. > typedef struct price_tag
  26. > {
  27. >     float            cost;
  28. >     BARCODE          code;
  29. >     struct price_tag *next;
  30. > } PRICE_INFO;
  31. > 
  32. > #endif
  33. > 
  34. > /* */
  35. > 
  36. > /* Untested code; call this "bar.h" */
  37. > 
  38. > #ifndef _BAR_H_
  39. > #define _BAR_H_
  40. > 
  41. > typedef struct barcode_tag
  42. > {
  43. >     char             number;
  44. > } BARCODE;
  45. > 
  46. > #endif
  47. > 
  48. > /* */
  49. > 
  50. > Of course, these are intentionally simple examples, and there are
  51. > obvious ways to solve the problem by merging the two header files.
  52. > Imagine, however, that it is undesirable to merge the header files --
  53. > each of them deals with a different library of functions, and need to
  54. > be kept seperate to maintain modularity.
  55. > 
  56. > The obvious problem, now, is that a source file that needs to use
  57. > "foo.h" will have to include "bar.h" prior to including "foo.h", which
  58. > is a nasty situation stylistically.  Including another header file
  59. > within a header file is even worse.
  60. > 
  61. > My question is: how can you keep the two header files seperate, and
  62. > still get away with not having header file dependancies or inclusion
  63. > orders?
  64.  
  65. Why is including another header file in a header file worse?  It's
  66. often the appropriate solution.  That's what I'd do here.
  67.  
  68. Note that names beginning with an underscore and an upper case letter
  69. are reserved for use by the implementation.  You should not define
  70. such names yourself.  Use something like FOO_H instead.
  71.  
  72. Michael M Rubenstein
  73.